The present invention is related to an apparatus and method for performing developmental testing on a target system electronic design that includes many multi-transistor components. Such a design could be implemented as a system-on-a-chip or on a PC board.
As IC design complexity increases so does the time required to verify each design. A first step in typical current design verification methodology is to divide a design into various functional blocks, and then to design and verify each block separately. These blocks (also referred to as "components") may be from 50 gates to 100,000 gates or more in complexity and may require computer simulation runs of between a few hours and a few days to verify the block to a first order of confidence. In the context of this application the term "component" refers to this type of block.
A great challenge is presented, however, by the necessity of verifying the performance of an entire target system that is composed of a group of these already verified blocks. Because a target system design may include several million gates, a week of computer time may be needed to simulate the entire design. Moreover, a new simulation run must be performed each time the design is changed, greatly slowing the design process. In addition, a target system simulation can only be executed when a complete circuit description in electronic file format (a "net list") is available. In the future, it will be increasingly typical for a foundry to manufacture target systems that include some components that are proprietary to the foundry and other components that are designed by the target system designer. Typically, no net lists will be available for the foundry proprietary components.
Moreover, owners of proprietary circuit designs sometimes offer a file in an encoded, FPGA loadable format, thereby permitting implementation of the circuit design on an FPGA. Because of the encoding, however, the user is unable to derive the net list from this file. The function of such a component could not be simulated because of the unavailability of the net list.
Further complicating the process, most electronic systems today are "embedded systems" in the respect that they include both hardware and embedded software components. In the past, the dividing line was relatively simple. A microprocessor was chosen as the core of the system and this processor was then interfaced to its surrounding environment with application specific integrated circuits (ASICs) and other custom logic. This completed the basic hardware system, and a prototype board was built and used for software development. For tasks that were speed critical, some software routines could be implemented in custom hardware, but with a significant cost both in production and in development. Today, IC designers have the ability to manufacture large ICs that implement many tasks in hardware that formerly were performed by software, thus creating much faster systems. Because much of the hardware in a system-like this is designed to work with specific software, this requires that both the hardware and software be developed together. Unfortunately, software verification requires an order of magnitude more simulation patterns to verify than does hardware verification. There is currently no means of running these verification tests until a hardware prototype of the system exists, typically at the completion of hardware design. If a hardware error is uncovered during the software testing, it forces a difficult decision between a very expensive change to the finalized hardware design or a cumbersome, and perhaps slow, software work-around.
To ease the task of debugging software that resides in an embedded system, various special software tools have been developed. These packages typically include a ROM monitor component that resides in a read only memory assembly that is accessible to the microprocessor. When the microprocessor is booted it begins operation using the instructions in the ROM monitor. Another debug package component resides on a test computer that is connected to some of the pins of the microprocessor. The test computer can instruct the ROM monitor to load the software program that runs on the microcontroller with a breakpoint that causes operation to jump to the ROM monitor. The ROM monitor instructions cause the microcontroller CPU to send specified register contents out through the pins that are connected to the test computer for display to a developer. At present it is generally not possible to use this type of debug package to its fullest effect until all the hardware components are completed and an entire system is ready to be tested. Alternatively, the debug package could be used without the hardware components. This will, of course, not find problems that occur in the interaction of the software and the hardware. The early use of such a debug package would be tremendously beneficial to software developers in their efforts to debug software prior to the time when an entire system has been constructed.
In order to speed up the verification time of a target system design, various methods have been used. These generally fall into three categories: hardware modelers, emulators and simulation accelerators.
Hardware modelers address the above noted problematic situation in which a net list does not exist for one of the target system blocks. In this situation it is generally the case that a physical embodiment of the block exists in the form of an IC or a bonded out IC core (a portion of an IC that has been extracted and equipped with connector pins). A hardware modeler is designed to connect such a physical embodiment to a computer executing a simulation model (a "simulator"). Unfortunately, a single hardware modeler only connects a single physical embodiment to the simulator. Although an additional physical embodiment could be connected to the simulator by an additional hardware modeler, communications between the two physical embodiments would have to be implemented by the simulator, greatly slowing system performance. Because of this, hardware modelers generally do not greatly accelerate the simulation process for complex systems.
At least one current hardware modeler allows a user to place one or more physical components on adapter boards that are then inserted into the modeler. This modeler is also connected to a simulator. The modeler allows the designer to incorporate the components on the adapter boards into an event-driven simulation, thus obtaining an accurate model of the component without the need for a net list. Unfortunately, all connections between the physical embodiments must, nevertheless, go through the simulator. If a microprocessor is placed in the hardware modeler, it could be used to do hardware/software co-verification, except that because all communications must be routed through the simulator it is far too slow to be useful for that purpose.
One recently released product is targeted at taking a microprocessor IC or bonded out core and connecting it to an event-driven simulator, utilizing software debugging tools to allow hardware and software designers to use a real hardware model of the core processor during system design verification. The overall speed of execution of a system being designed with this product, however, will always be limited by the speed of the event-driven simulator, where the major portion of the design exists. This will be too slow for effective hardware/software simulation.
Another available product is intended to be a system level rapid prototyping solution. The product consists of a generic prototyping board that has two prototype areas with prepunched holes and no ICs attached. The prototype areas are where the customer places ICs or field programmable gate arrays (FPGAs) that represent different building blocks in an IC or printed circuit board design. All of the pins in both prototyping areas can then be routed (any pin to any pin) via a set of proprietary custom crossbar switches. These crossbar switches are programmable, so that mistakes in routing can easily be corrected. This product facilitates the creation of a flexible prototype that can run close to a target system's design speed and can be used for software development after the hardware design is complete or for system level verification. Unfortunately, because there is no integration of either software debugging tools or an event-driven simulator with this product, it does not allow easy hardware/software co-verification during the development stages. Moreover, when the system includes three or more components this device is not of great utility.
Simulation accelerators are basically customized parallel processing computers that speed up the simulation run time significantly. Accelerators, however, do not address the problem noted above with respect to any system component for which no net list is available.
Emulators use FPGAs to emulate the design being created. Using software tools, the design netlist is subdivided between a hardware emulation set of FPGAs. An interconnect set of FPGAs is used to reconfigurably interconnect the hardware emulation set of FPGAs. Emulators are significantly faster than other simulation methods, but they make significant restrictions on the format of the design source files and are difficult to expand significantly to emulate a system on a chip.
The new target system design methodology will rely heavily upon the reuse of virtual components (VCs). The VCs would typically be available to the developer in the form of FPGA loadable encoded files. In addition a contract foundry would have access to a set of production tools, including photolithography masks, for etching the VC onto silicon. A new business area is being developed that consists of designing and selling various VCs to be incorporated into target systems. The actual system design will normally be a synchronous design using a collection of VCs and normally adding several new custom design blocks to create a complete system. The partitioning of the design into medium sized design blocks will be done by the designer and these blocks will be interconnected by two to four standard buses.
What is, therefore, needed but not yet available, is an apparatus and method for verifying a multicomponent target system that may rapidly model a significant portion of the target system and may, furthermore, be easily connected to a simulator or software debugging tool.